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Description 

[0001] The present invention relates generally to the 
monitoring of an information technological (IT) network, 
and more particularly to a method, system and a com- 5 
puter program of installing monitoring agents on moni- 
tored nodes for monitoring objects in an IT network. 
[0002] Nowadays, as information systems become 
ubiquitous, and companies and organizations of all sec- 
tors become drastically dependent on their computing 
resources, the requirement for the availability of the 
hardware components and software components (ap- 
plications) of an IT network and of services based on it, 
(hereinafter all three are generally referred to as "ob- 
jects") is increasing while the complexity of IT networks 
is growing. 

[0003] There are monitoring systems available which 
enable the availability and performance of objects within 
an IT network to be monitored and managed. 
[0004] For example, Hewlett-Packard offers such a 
product family under the name "HP OpenView". A per- 
sonal computer, node, network interconnect device or 
any system with a CPU is called a node. The nodes of 
an IT network monitored by such a monitoring system 
are called monitored nodes. On a monitored node or 
somewhere in the network with access to the monitored 
node, a program or process runs as a background job 
which monitors the occurrence of certain events (e.g. 
application errors) at the node and generates event-re- 
lated messages according to a "policy", i.e. according 
to a set of instructions and/or rules which can be defined 
by a user. Such a program or process is called an 
"agent". An agent is not limited to passive monitoring, 
e.g. by collecting error messages. Rather, it can carry 
out active monitoring of hardware and processes. For 
example, an agent can periodically (e.g. every five min- 
utes) send requests to a process (e.g. an Oracle proc- 
ess) to find out whether the process is still running. A 
response saying that the process is no more running (or 
the absence of a response) may also constitute an 
"event". The messages generated by the agents are col- 
lected by a monitoring server which stores and process- 
es them and routes the processing results to a monitor- 
ing console by means of which an IT administrator or 
operator can view the status and/or performance of the 
IT objects. 

[0005] A monitoring system of that kind increases the 
availability of the IT objects under consideration since it 
enables a fault or failure of a component of the moni- 
tored network to be quickly detected so that repair action 
or the like can immediately be started. 
[0006] However, for many mission or business-critical 
applications, the level of availability achieved by moni- 
toring alone is not sufficient. This class of services in- 
cludes online transaction processing, electronic com- 
merce, internet/World Wide Web, data warehousing, 
decision support, telecommunication switches, Online 
Analytical Processing, and control systems. Such appli- 



cations generally run 24 hours a day. The nodes on 
which these applications are executed must run perpet- 
ually and, therefore, demand high availability. 
[0007] There are many different concepts for provid- 
ing high availability IT services (see J.V. Carreira et al.: 
"Dependable Clustered Computing", in: R. Buyya (Edi- 
tor): High Performance Cluster Computing, Architec- 
tures and Systems, Vol. 1 , 1 999, pages 94-1 1 5). One of 
these concepts uses a cluster of at least two nodes. In 
what is called an active/standby configuration, one or 
more critical applications or parts of applications, run on 
one of the two nodes, the first or primary node. A cluster 
operating system checks permanently whether a 
"failover" condition (e.g. a failure or an error, which con- 
stitutes a forewarning of a failure, of the critical applica- 
tion or a hardware resource impairing it) has occurred. 
If such a failover condition in the primary node is detect- 
ed, the critical application(s) is switched to the other 
node, the second or secondary node, thus avoiding 
downtime and guaranteeing the availability of the appli- 
cation^), which is therefore also denoted as "protected 
application". When the primary node has been repaired 
(after a failure), the critical application can be switched 
back from the secondary node to the primary node (see 
Carreira, pages 94-115, in particular pages 102-103). 
The application or part of an application which forms a 
logically connected entity in a "cluster view" and is 
switched from one the other node in the case of failover, 
is also called "cluster package". Such HA clusters are 
advantageous compared to conventional specialized 
hardware-redundant platforms which are hardware-re- 
dundant on all levels (including power supplies, I/O 
ports, CPU's, disks, network adapters and physical net- 
works) in order to individually eliminate any single point 
of failure within the platform, since they require the use 
of proprietary hardware and software. In contrast, the 
cluster solution allows users to take advantage of off- 
the-shelf industry standard and cheap components. 
[0008] The supervision performed by the cluster op- 
erating system as to whether a failover condition has 
occurred and the monitoring of the network objects car- 
ried out simultaneously and independently by the mon- 
itoring system have to be differentiated from each other. 
The first one is a specialized task carried out within the 
cluster by a cluster operating system. An example of 
such tasks carried out by a cluster operating system is 
described in WO 01/84313 A2. A cluster is formed of a 
set of single resources. This resources are monitored 
on each of the nodes by agents. With the detection of a 
failure of a critical resource it is decided to fail-over (i.e. 
to switch) an application concerned from one machine 
to another machine of the cluster. Events may also be 
published so that other interested applications and man- 
agement agents can learn of status changes and reas- 
signments of components (page 17, line 28 - page 18, 
line 2). 

[0009] The monitoring of the network objects carried 
out simultaneously and independently by the monitoring 
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system, is a platform-independent application capable 
of monitoring complex networks as a whole and of being 
easily adapted to networks of different topologies. Mon- 
itoring systems, such as the HP OpenView system, also 
allow the monitoring of such high availability (HA) clus- s 
ters. Both cluster nodes are then provided with a respec- 
tive agent. Each of these agents monitors the occur- 
rence of events relating to the monitored application and 
generates event-related messages. Both agents per- 
manently check whether the application under consid- io 
eration is running. Since the monitored application runs 
only on one of the two cluster nodes at a time, one of 
the two agents permanently generates messages indi- 
cating that the application is not running, although it is 
intended that the application is not running on that node, is 
The messages from both agents are processed up- 
stream by the monitoring server which takes into ac- 
count on which one of the two nodes the application is 
inte nded to be currently acti ve. Th is way of processing 
the monitoring messages is relatively complicated. 20 
[0010] In order to avoid the need for the monitoring 
server to process "false" error messages, a "work- 
around" solution has been proposed according to which 
the user can modify the cluster package software in 
such a way that it reconfigures both agents in the case 25 
of a failover so as to avoid the generation of "false" error 
messages. 

[0011] The invention provides a method of installing 
monitoring agents on monitored nodes for monitoring 
objects within an IT network. The IT network has non- 30 
cluster nodes and at least one HA cluster comprising a 
first and a second cluster nodes. At least one cluster 
package is arranged to run on the high-availability clus- 
ter, wherein a cluster operating system initiates, when 
a failover condition is detected for the cluster package 35 
at the first cluster node, a failover to the second cluster 
node is initiated. The monitoring agents monitor the oc- 
currence of events and generate event-related messag- 
es for a monitoring server. First and a second monitoring 
agents associated with the first and second cluster *o 
nodes form a monitoring agent system of the cluster. 
The first and second agents of the monitoring agent sys- 
tem are arranged to receive information from the cluster 
operating system of the high-availability cluster indicat- 
ing whether the cluster package is currently active on 45 
the first or second cluster node, respectively. 
[0012] Depending on the cluster-package-activity in- 
formation, the monitoring activity relating to the cluster 
package is activated in the one of the first and second 
agents associated with the cluster node on which the so 
cluster package is currently active and is de-activated 
in the other one. The method comprises: automatically 
adapting, upon installation, the monitoring agents which 
are installed on the cluster nodes such that they are ar- 
ranged to receive the cluster-package-activity informa- 55 
tion and exhibit said dependency of their monitoring ac- 
tivity on cluster-package-activity information, whereas 
the monitoring agents which are installed on the non- 



cluster nodes are arranged not to exhibit a dependency 
of their monitoring activity on cluster-package-activity. 
[001 3] According to another aspect, the invention pro- 
vides a system for monitoring objects within an IT net- 
work includes a monitoring server and monitored nodes. 
The system comprises non-cluster nodes and at least 
one HA cluster which comprising: first and a second 
cluster nodes; a cluster operating system which initi- 
ates, when a failover condition is detected for a cluster 
package running on the first cluster node, a failover to 
the second cluster node; and monitoring agents which, 
when installed on the non-cluster nodes or the cluster 
nodes monitor the occurrence of events and generate 
event-related messages for the monitoring server. First 
and second monitoring agents installed on and associ- 
ated with the cluster nodes form a monitoring agent sys- 
tem of the cluster. The first and second agents receive 
information from the cluster operating system indicating 
whether_the_cluster packagejs currently active on the 
associated cluster node. Depending on that information, 
the monitoring activity relating to the cluster package is 
activated in the one of the first and second agents which 
is associated with the cluster node on which the cluster 
package is currently active and is de-activated in the 
other one. The agents are automatically adapted, upon 
installation on a cluster node, to receive the cluster- 
package-activity information and exhibit said dependen- 
cy of their monitoring activity on cluster-package-activity 
information, but, upon installation on a non-cluster node, 
not to exhibit a dependency of their monitoring activity 
on cluster-package-activity. 

[001 4] According to still another aspect, the invention 
is directed to a computer program including program 
code for execution on a network comprising a monitor- 
ing server and monitored nodes, including non-cluster 
nodes (2) and at least one HA cluster comprising first 
and second cluster nodes. A cluster operating system 
initiates, when a failover condition is detected for a clus- 
ter package running on the first cluster node, a failover 
to the second cluster node. The program code consti- 
tutes, when installed on the non-cluster nodes or the 
cluster nodes an agent for monitoring the occurrence of 
events and generating event-related messages for the 
monitoring server. First and second agents, when in- 
stalled on the cluster nodes of the cluster, form a mon- 
itoring agent. The first and second agents receive infor- 
mation from the cluster operating system indicating 
whether the cluster package is currently active on the 
associated cluster node. Depending on that information, 
the monitoring activity relating to the cluster package is 
activated in the one of the first and second agents which 
is associated with the cluster node on which the cluster 
package is currently active and is de-activated in the 
other one. The agents are automatically configured, up- 
on installation on a cluster node, to receive the cluster- 
package-activity information and exhibit said dependen- 
cy of their monitoring activity on cluster-package-activity 
information, but, upon installation on a non-cluster node, 
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not to exhibit a dependency of their monitoring activity 
on cluster-package-activity. 

[0015] Other features are inherent in the disclosed 
method, system and computer program or will become 
apparent to those skilled in the art from the following 
detailed description of embodiments and its accompa- 
nying drawings. 

[0016] In the accompanying drawings: 

Fig. 1 shows a high-level architecture diagram 

of a monitored IT network; 
Figs. 2a, b illustrate a first example of a monitored 

HA cluster with one monitored cluster 

package; 

Figs. 3a, b illustrate a second example of a moni- 
tored HA cluster with two monitored clus- 
ter packages and a bi-directional failover 
functionality; 

Fig. 4 is a flow chart of a method carried out by 

an agent in the embodiment of Figs. 2a, b. 
Fig. 5 illustrates an agent deployment process. 

[0017] Fig. 1 shows a high-level architecture diagram 
of a monitored IT network. Before proceeding further 
with the description, however, a few items of the pre- 
ferred embodiments will be discussed. 
[001 8] In the preferred embodiments, objects of an in- 
formation technical (IT) network are monitored as to 
their availability and performance by a monitoring sys- 
tem. (The term "IT network" also includes telecommu- 
nication networks). Such monitored objects comprise 
hardware devices, software and services. A node is a 
network object such as a PC, node or any system with 
a CPU. A node is called a "monitored node" if it and/or 
applications or processes running on it are monitored 
by the monitoring system. Services are, for example, 
customer-based or user-oriented capabilities provided 
by one or more hardware or software components within 
a computing environment. For instance, services can be 
commercial applications (such as Oracle), Internet node 
applications (such as Microsoft Exchange), or internal 
(e.g. operating-system-related) services. 
[0019] The monitoring may comprise passive moni- 
toring (e.g. collecting error messages produced by the 
objects) or active monitoring (e.g. by periodically send- 
ing a request to the object and checking whether it re- 
sponds and, if applicable, analyzing the contents of the 
response). Preferably, a monitoring of applications is 
carried out, rather than a simple resource monitoring. 
Besides pure monitoring tasks, in the preferred embod- 
iments the monitoring system can also carry out man- 
agement tasks, such as error correcting or fixing tasks, 
setting tasks and other network services control tasks. 
[0020] An event is a (generally unsolicited) notifica- 
tion, such as an SNMP trap, CMIP notification or TL1 
event, generated e.g. by a process in a monitored object 
or by a user action or by an agent. Typically, an event 
"represents an error, a fault, change in status, threshold 



violation, or a problem in operation. For example, when 
a printer's paper tray is empty, the status of the printer 
changes. This change results in an event. An "event" 
may also be established by a certain state change in the 

5 monitored object detected by active monitoring. 

[0021] An agent is a program or process running on 
a remote device or computer system. An agent commu- 
nicates with other software, for example it responds to 
monitoring or management requests, performs monitor- 

10 ing or management operations and/or sends event no- 
tification. In the preferred embodiments, the agents are 
designed to run on the monitored nodes. In other pre- 
ferred embodiment, the agents run nodes that are re- 
mote from the monitored node. There may be one agent 

15 for each monitored cluster package. In other embodi- 
ments, one agent can monitor several cluster packages. 
If several cluster packages or processes run on the 
same cluster node, they will be preferably monitored by 
one and the same agent associated with this cluster 

20 node. The agent is configured by a set of specifications 
and rules, called policy, for each cluster package appli- 
cation or process to be monitored. Policies can be user- 
defined. A policy tells the agent what to look for and what 
to do when an event occurs (and, what events to trigger, 

25 jf the agent carries out active monitoring). For example, 
according to a particular policy, an agent filters events 
and generates messages which inform the monitoring 
server about the occurrence of certain events and/or the 
status and performance of the monitored application or 

30 process. The monitoring server collects event and per- 
formance data, processes them and routes the results 
to a monitoring console (a user interface). In the pre- 
ferred embodiments, the monitoring server also central- 
ly deploys policies, deployment packages, and agents, 

35 as directed by the user, and stores definitions and other 
key parameters. In the preferred embodiments, services 
are monitored platform-independently. For example, dif- 
ferent operating systems can be implemented on the 
various monitored nodes. 

40 [0022] In a high-availability (HA) cluster there is a pri- 
mary node on which the critical application runs, and a 
secondary node which serves as a backup for the critical 
application. However, generally, only a part of one or 
more applications (for example, a part of an SAP appli- 
es cation) runs on a cluster node and is backed up by the 
secondary node. The application or part of an applica- 
tion which forms a logically connected entity in a cluster 
view and is backed up, is also called "cluster package". 
The two cluster nodes are interconnected. If a failover 

50 condition is detected, a cluster operating system initi- 
ates the switching of the critical application, the cluster 
package, from the primary to the secondary node. The 
HA cluster is transparent for the rest of the IT network 
in the sense that it appears to the "outside" as a corre- 

55 sponding standard (non-cluster) node. 

[0023] A failover condition is a failure of the critical ap- 
plication or a resource, on which it depends, for exam- 
— pie, if the critical application produces no or incorrect 
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results, e.g. due to software faults (bugs) or due to hard- 
ware failures, such as a crash of a disk that the applica- 
tion needs. Preferably, a failover is initiated before such 
a serious failure occurs. This can be done if already a 
kind of forewarning, which is called an "error", consti- 
tutes a failover condition. For example, some time be- 
fore the external behavior of a system is affected, a part 
of its internal state may deviate from the correct value. 
If such an error is detected, which can be, for instance, 
an internal program variable with an invalid value, a 
failover can be carried out before the failure occurs. An- 
other error which has such forewarning characteristics 
and can therefore be used as a failover condition is a 
decline in the performance of a hardware device. 
[0024] In embodiments with only one monitored clus- 
ter package, or with several monitored cluster packages 
which, however, normally run on one and the same clus- 
ter node, the HA cluster is in an Active/Standby config- 
uration. In this scheme, only the primary node is active, 
whereas the secondary node is in standby mode. The 
two machines do not need to be absolutely identical: 
The back-up machine just needs the necessary resourc- 
es (disk, memory, connectivity etc.) to support the criti- 
cal application(s). It can be a lower-performance ma- 
chine as it only needs to keep the application(s) running 
while the primary node is repaired after a failover. Like- 
wise, an Active/Active configuration can be used, 
wherein all nodes and the cluster are active and do not 
sit idle waiting for a failover to occur. For instance, an 
application A can run on node X and an application B 
on node Y. Then, node Y can backup the application A 
from node X, and node X can backup the application B 
from node Y. The solution is sometimes referred to as 
providing bi-directional failover. This Active/Active mod- 
el can be extended to several active nodes that backup 
one another. However, it is common to these different 
models that, when referring to a particular application, 
one node can be considered active (this is the node on 
which the particular application is running) and the other 
node as being in the standby mode for this particular 
application. Therefore, in the present specification, the 
expression "the node is active / in the standby mode" 
means that it is active or in the standby with respect to 
a particular critical application cluster package under 
consideration, but does not necessarily mean that the 
machine itself is generally active or in the standby mode. 
[0025] The HA clusters of the preferred embodiments 
can be likewise configured according to what is called 
the share-nothing cluster model or the share-storage 
cluster model. In the share-nothing cluster model, each 
cluster node has its own memory and is also assigned 
its own storage resources. Share-nothing clusters may 
allow the cluster nodes to access common storage de- 
vices or resources. In both models, a special storage 
interconnect can be used. 

[0026] The HA clusters of the preferred embodiments 
use available cluster operating systems, such as 
Hewlett Packard MC/Serviceguard, Microsoft Cluster 



Node (formerly codenamed Wolfpack) or VeritasClus- 
ter. Further, for a particular application (such as Oracle 
Database) a definition has to be provided of what must 
happen when a failover occurs. Such software can be 
5 considered as an interface between the cluster operat- 
ing system and the particular critical application and 
forms part of the cluster package. For example, for the 
Oracle Database the corresponding software is "Oracle 
Clusterpackage". Commonly, such "failover middle- 
ware" is a part of the respective critical application. 
[0027] In the preferred embodiments, the agent sys- 
tem is constituted by at least one agent for each cluster 
node of a monitored cluster. The agents actively or pas- 
sively receive information indicating whether the cluster 
package is currently active on the associated cluster 
node. The monitoring and the receipt of this information 
are separate tasks which are carried out in parallel and 
independently. Based on this information, the message 
generation for the respective cluster package is activat- 
ed or de-activated. An agent is activated to monitor the 
application (and, thus, generates monitoring messages) 
when the cluster package is active on the cluster node 
associated with the agent, and an agent is de-activated 
(and, thus, generates no erroneous monitoring messag- 
es indicating that the cluster package is unavailable) 
when the cluster package is unavailable on the cluster 
node associated with the agent. This solution can be 
based on standard agents and standard policies, such 
as those which can be used with non-cluster nodes, and 
does not require modifications of the cluster package 
software. 

[0028] In the preferred embodiments, the agents re- 
ceive this information from the cluster operating system. 
In order to receive said information, in one embodiment 
the agent periodically sends a corresponding request to 
the cluster operating system, and receives a corre- 
sponding response from it which indicates whether the 
associated cluster node is active or inactive. In another 
embodiment, the agent is registered at the cluster oper- 
ating system upon initialization, which then notifies the 
agent periodically and/or in the case of a change about 
the activity status of the associated cluster package. 
[0029] As already mentioned above, the expressions 
"active" and "inactive" or "standby" may refer either to a 
cluster node as a whole or a particular cluster package. 
[0030] In the preferred embodiments, the agent of a 
cluster node generates messages according to monitor- 
ing rules. In the most preferred embodiments, there is 
also at least one overlaid rule which pertains to cluster 
package activity. This rule is generally not part of the 
policy containing the monitoring rules, but it is associat- 
ed with the policy and the monitored cluster package. 
The overlaid rule causes the agent not to evaluate the 
monitoring rules (i.e. not to generate erroneous moni- 
toring messages) if the information received from the 
cluster operating system indicates that the monitored 
cluster package is inactive on the associated cluster 
node. 
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[0031] In the preferred embodiments, the agents 
monitor the cluster package on the associated cluster 
nodes and generate messages according to a policy 
which includes monitoring rules. These rules can be de- 
fined by a user. The set of available rules for monitored 
clusters is preferably the same as (or at least comprises) 
the set of rules for monitored non-cluster nodes. In other 
words, a cluster is transparent for the user who wants 
to define rules for the monitoring task of an agent. The 
user can define the monitoring task for a monitored clus- 
ter as if it were a standard (non-cluster) node. 
[0032] As mentioned above, there is a difference be- 
tween monitoring non-cluster nodes and clusters: In the 
most preferred embodiments, an agent, which is asso- 
ciated with a cluster node in standby mode, generates 
no erroneous error messages indicating that the moni- 
tored cluster package is not running on that node, 
whereas an agent of a non-cluster node is commonly 
permanently ready to generate monitoring messages. 
This functionality, i.e. the ability to receive said informa- 
tion and to exhibit the above-described dependency of 
the message generation on the activity state of the as- 
sociated cluster node with regard to the monitored clus- 
ter package is automatically provided upon the installa- 
tion of the agent and/or the policies (in some embodi- 
ments, the user may be required to expressly indicate 
to the system that the agent shall operate on a cluster 
node rather than on a non-cluster node). This allows the 
user to define the policies for a cluster in the same way 
as for a non-cluster node. 

[0033] The preferred embodiments of the computer 
program comprise program code which, for example, is 
stored on a computer-readable data carrier or is in the 
form of. signals transmitted over a computer network. 
The preferred embodiments of the program code are 
written in an object-oriented programming language (e. 
g. Java or C++). The program code can be loaded (if 
needed, after compilation) and executed in a digital 
computer or in networked computers, e.g. a monitoring 
server networked with monitored nodes. 
[0034] In the preferred embodiments, the software 
has a central deployment functionality: the user can as- 
sign one or more policies to a monitored node from a 
user interface (console) and the program code automat- 
ically installs ("deploys") the intelligent agents and poli- 
cies at the cluster node. Upon installation the agents 
and/or policies are automatically adapted to the require- 
ments of the monitored node. For example, the overlaid 
rule which obscures the package status by inactivating 
message generation is automatically added to the 
standard monitoring rules, and also the agent's interface 
to the cluster operating system for the receipt of the ac- 
tivity information which is one of the two types (periodi- 
cal request or registration) is automatically installed. 
Thus, the agent and policy deployment to a cluster is 
transparent for the user, and requires no additional man- 
ual intervention. 

[0035] —Returning now to Fig. 1, it shows a high-level 



architecture diagram of a preferred embodiment of a 
service monitoring system 1 . The system 1 comprises 
two monitored nodes, namely a non-cluster node 2 and 
a high-availability (HA) cluster 3. The HA cluster 3 is 

5 constituted of two nodes, a primary cluster node 4 and 
a secondary cluster node 5, as well as a cluster control- 
ler 6 with a cluster operating system (COS) 20, a storage 
interconnect 7 and a cluster storage 8. The node 2 and 
the HA cluster 3 are a part of a monitored IT network. 

10 Non-critical applications or services 9a-c run on the 
node 2. A critical application 10, also called cluster pack- 
age, runs on the primary cluster node 4 of the HA cluster 
3. A monitoring software component 11 (an "agent") is 
installed on each of the monitored nodes 2, 4, 5 which 

15 runs automatically as a background task. The agents 1 1 
receive event notifications and collect performance data 
from the monitored applications and services 9a-c, 10 
and from hardware resources used by them. They col- 
lect and evaluate these event notifications and perform- 

20 ance data according to policies 1 2a-c, 1 3. The policies 
comprise sets of collection and evaluation rules which 
are defined by a user via a user interface 14. Although 
there is only one agent 11 per monitored node 2, 4, 5, 
there is one policy 12, 13 per monitored application or 

25 cluster package 9, 10. Therefore, in Fig. 1 there are 
three policies 12a-12c associated with the agent 11 
which monitors the three applications 9a-c, whereas 
there is only one policy 1 3 associated with the agent 1 1 a 
since, in Fig. 1, it monitors only one application (cluster 

30 package) 10. It is likewise possible that several (1, 2, 
3 ... M) policies are associated with one application. For 
example, there may be one policy defining the monitor- 
ing of processes relating to the application, and another 
policy for defining the monitoring of the application's log- 

35 file. 

[0036] Depending on which events occur and what is 
indicated by the collected data, the agents 11,11a filter 
and evaluate them according to the policies 12,13, and 
send monitoring messages 15 to a service monitoring 

40 server 16 which stores the messages in a monitoring 
database 17, processes them and sends the messages 
and the processing results to a navigator display 18 in- 
cluding a message browser 19. In the navigator display 
18, the network and the services provided by it are vis- 

45 ualized for the user in the form of a two-dimensional net- 
work and service map showing the status of the individ- 
ual monitored services. In the message browser 19 the 
most relevant messages are displayed. The user can 
add rules by the user interface 14 which define how the 

50 service monitoring server 1 6 is to process the messages 
15. 

[0037] In the HA cluster 3, the cluster package 10 is 
shown to be active on the primary cluster node 4 and 
inactive on the secondary cluster node 5. Although an 
55 agent 11b is installed on the standby cluster node 5, it 
does not generate erroneous monitoring messages due 
to notification data received from the cluster operating 
"system 20 which tell the agent 11b that the monitored 
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cluster package 1 0 is currently inactive on its associated 
node 5. Rather, based on the notification data, only the 
agent 11a associated with the cluster node 4 on which 
the cluster package 10 is currently active generates 
monitoring messages 1 5 relating to the cluster package 
10. More detailed views of the HA cluster are shown in 
Figs. 2 and 3. 

[0038] Fig. 2 illustrates the case of an HA cluster 3 
with only one monitored cluster package 1 0 before (Fig. 
2a) and after (Fig. 2b) a failover has been carried out. 
In the state before the failover, the cluster package 10 
is active on the primary cluster node 4. It is inactive on 
the secondary node 5, but the secondary node 5 is ready 
to back it up from the primary node 4. An agent 11a is 
installed on the primary node 4, and another agent 11b 
is installed on the secondary node 5. A policy 13 for 
monitoring the cluster package 10 and an overlaid rule 
22 are associated with each of the agents 1 1 a, 1 1 b. The 
policy 13 comprises monitoring rules, which define what 
and how to collect and how to generate monitoring mes- 
sages. The overlaid rule 22 defines that no event col- 
lection and/or message generation shall be carried out 
when the associated cluster package is inactive. The 
cluster operating system 20 on the cluster controller 6 
permanently checks the cluster package 10 on the ac- 
tive primary node 4 and resources on which the cluster 
package 10 depends for the appearance of a failover 
condition. The cluster operating system 20 also is in 
communication with the agents 11a, 11b. It is aware of 
on which one of the nodes 4, 5 the cluster package 10 
is currently active and on which one it is inactive. There 
are two different embodiments of how the agents 11a, 
11b can obtain this information pertaining to cluster- 
_ . node.activity (Fig. 4): According to a first embodiment, 
the agents a, 1 1 b periodically send requests to the clus- 
ter operating system 20 which returns the requested ac- 
tivity/standby information. According to the other em- 
bodiment, the agents 1 1 a, 1 1 b are registered at the clus- 
ter operating system 20 once upon initialization, and 
then receive automatically a notification from the cluster 
operating system 20 when the activity/standby mode 
changes (and, optionally, also periodically status notifi- 
cations). This second embodiment is preferred, howev- 
er, it is not supported by all available cluster operating 
systems. In Fig. 2a, the agent 1 1 a is notified (or informed 
by a response) that on its associated node 4 the cluster 
package 10 is active, whereas agent 11b is notified that 
on its associated node 5 the cluster package 1 0 is inac- 
tive. Accordingly, the overlaid rules 22 command the 
agent 1 1 a to evaluate the monitoring rules defined in the 
policy 13 and the agent 1 1 b not to evaluate these mon- 
itoring rules. Consequently the agent a of the node 4 on 
which the cluster package 1 0 is active generates mon- 
itoring messages 15, whereas agent 11b of the node 5 
on which the cluster package 10 is inactive does not 
generate monitoring messages relating to the cluster 
package 1 0. The monitoring messages 1 5 generated by 
the active node's agent 11a are sent to the monitoring 



server 16 which uses them for monitoring the cluster 3. 
Thus, from outside the cluster 3 the messages 15 ap- 
pear as if they came from a corresponding standard 
(non-cluster) node. 

5 [0039] As mentioned above, the cluster operating 
system 20 checks the primary node 4 and the active 
cluster package 10 running on it for the appearance of 
a failover condition. Such a failover condition can be a 
failure of a hardware resource such as a LAN card, a 

10 hard disk, a CPU etc. Other failover conditions are soft- 
ware related. For instance, an electromagnetic interfer- 
ence, a program bug or a wrong command given by an 
operator may cause a program failure. Preferably, a 
failover condition is constituted not only of such serious 

15 failures, but already of errors which are forewarnings of 
a failure, such as a hardware performance degradation 
or the occurrence of an internal program variable with 
an invalid value. The cluster package 10 may be able to 
compensate for such errors and prevent the system 

20 from failing for a certain time so that the processing can 
be continued on the secondary node 5 practically inter- 
ruption-free. The detection of such a hardware or soft- 
ware failure or error constitutes a failover condition. Up- 
on its detection, the cluster controller 6 initiates the 

25 failover (indicated in Fig. 2a by an arrow). The second- 
ary node 5 backs up the cluster package 10 automati- 
cally and transparently, without the need for administra- 
tor intervention or client manual reconnection. In the 
second embodiment, the agents 11a and 11b are noti- 

30 fied by the cluster operating system 20 that a failover of 
the cluster package 10 from the primary node 4 to the 
secondary node 5 is carried out. In the first embodiment 
this information is only requested from the cluster oper- 
ating system 20 which causes a small delay correspond- 

35 ing on average to half the request period. 

[0040] Fig. 2b illustrates the situation after the 
failover. Now, the cluster package is running on the sec- 
ondary node 5. The secondary node's agent 1 1 b gener- 
ates monitoring messages 15 based on the notification 

40 by the cluster operating system 20. The cluster package 
10 on the primary node 4 is now in an error state and, 
thus, inactive. Owing to the notification by the cluster 
operating system 20, the agent 11a generates no erro- 
neous messages indicating that the cluster package 10 

45 on the primary node 4 is now in an error state. After the 
errors or faults that caused the failover have been de- 
tected and diagnosed, recovery, repair and reconfigura- 
tion actions may take place. Then the reversed process 
of failover, which is termed tailback, can be carried out. 

so it consists basically of moving back the critical applica- 
tion 10 to the primary node 4, about which the agents 
11a and 11b are again notified. Then, the original mes- 
sage generation state is also re-established. 
[0041] Preferably, both agents 11a, 11b are perma- 

55 nently active in order to perform monitoring of the first 
and second nodes 4, 5 themselves, even if the cluster 
package 10 is inactive on the respective node. This pro- 
vides information as to whether the respective node is 
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able to back up the cluster package in the case of a 
failover. 

[0042] The failover capability can also be used effi- 
ciently for another important purpose: maintenance. 
Maintenance actions can be performed on the primary 
node by switching over the critical application to the sec- 
ondary node. On-line maintenance of that kind reduces 
or even eliminates the need for scheduled down times 
for maintenance tasks and software upgrades. 
[0043] The failover process commonly includes a 
number of resources to be switched over to the standby 
node. For example, the network identity of the nodes is 
switched. Using the TCP/IP protocol, this involves to dy- 
namically change the IP address associated with the pri- 
mary node's network card to that of the secondary 
node's network card. 

[0044] The policy 13 with monitoring rules defined by 
the user for the monitoring of the application (cluster 
package) 1 0 is the same as that the user would have to 
define for a corresponding monitoring of the same ap- 
plication running on a standard (non-cluster) node. The 
installation of the two agents 1 1 a, 1 1 b at the primary and 
secondary nodes 4, 5 together with the policies 13 as- 
signed to them is carried out automatically by the mon- 
itoring server 16, when the data model of the monitored 
IT network is configured so as to include the HA cluster 
3. In particular, the user does not have to enter the over- 
laid rules 22. But rather, this is also automatically done 
by the monitoring server 16 upon installation. The HA 
cluster 3 is thus transparent (e.g. it appears as a corre- 
sponding non-cluster node) for a user who configures 
the monitoring system 1 . 

[0045] Fig. 3 illustrates the case of an HA cluster 3' 
with two monitored cluster packages 10a' and 10b'. Al- 
though it is possible to host two or more cluster packag- 
es in an active/standby configuration corresponding to 
what is illustrated in Fig. 2, Fig. 3 shows an alternative 
in the form of an active/active configuration. Fig. 3a il- 
lustrates the state of the HA cluster 3' before and Fig. 
3b after a failover has been carried out. The above de- 
scription of Figs. 1 and 2 applies also to Fig. 3; the only 
differences are described below. 
[0046] With the active/active configuration of Fig. 3, it 
is avoided that the secondary node is normally idle and 
serves only for backup purposes. Rather, both nodes 
are normally active: a first monitored cluster package 
10a' runs on the primary node 4', and a second moni- 
tored cluster package 10b' runs on the secondary node 
5'. The primary node 4' is prepared to back up the sec- 
ond cluster package 10b' from the secondary node 5' in 
the case of a failover. Likewise, the secondary node 5' 
is prepared to back up the first cluster package 1 0a' from 
the primary node 4' in the case of a failover (see Carrei- 
ra, pages 102-103). A policy and an overlaid rule for 
each cluster package (here a policy 13a' and a monitor- 
ing rule 22a for the first cluster package 1 0a' and a policy 
13b' and a monitoring rule 22b' for the second cluster 
packaged 0b') are associated with each of the agents 



11a ' and 11b'. Thus, in the example of Fig. 3 with two 
cluster packages 10a', 10b', each agent 11a', 11b' has 
two policies 13a', 13b', although only one cluster pack- 
age 10a' or 10b 1 runs on each of the first and second 
5 nodes 4', 5'. Each of the policies 13a', 13b' comprises, 
for each of the cluster packages 1 0a\ 1 0b', a set of mon- 
itoring rules. In order to prevent the agents 1 1 a' and 1 1 b' 
from sending messages to the monitoring server 1 6 with 
regard to the one of the cluster packages 10b', 10a* 
which is intentionally not running on the respective node 
4', 5', the primary node's agent 11a' generates monitor- 
ing messages 1 5a only with regard to the first cluster 
package 10a', but generates no monitoring messages 
with regard to the second cluster package 10b'. Corre- 
spondingly, the secondary node's agent 11b' generates 
monitoring messages 1 5b only with regard to the sec- 
ond cluster package 10b', but generates no monitoring 
messages with regard to the first cluster package 10a'. 
.The mechanism for achieving that is the one described 
in connection with Fig. 2, however, the active/standby 
notifications or responses by the cluster operating sys- 
tem 20 are application-specific (of course, also in Fig. 2 
the notifications or responses may be application-spe- 
cific, although there is only one monitored cluster pack- 
age). 

[0047] In Fig. 3a, an arrow indicates that a failover is 
carried out in which the first cluster package 10a' is 
switched from the primary node 4' to the secondary node 
5'. Owing to the bi-directional structure of the active/ac- 
tive configuration, a failover can also be carried out in 
the opposite direction, such that the second cluster 
package 10b' is switched from the secondary node 5' to 
the primary node 4'. 
_[0048] Fig. 3b illustrates the operating state of the 
cluster 3' after the failover indicated in Fig. 3a has been 
carried out. Both cluster packages 10a', 10b' now run 
on the secondary node 5', and the secondary node's 
agent 1 1 b' generates monitoring messages 1 5a, 1 5b for 
both cluster packages 10a', 10b'. On the other hand, the 
cluster package 10a' does not run on the primary node 
4' any more, and the primary node's agent 11a' gener- 
ates no error messages reflecting the fact that neither 
of the cluster packages 10a', 10b' is running on the pri- 
mary node 4'. After the fault which has caused the 
failover has been repaired, the normal operational state 
according to Fig. 3a is restored by a failback. 
[0049] The bi-directional active/active cluster of Fig. 

3 with two nodes can be extended to a system with 3, 

4 ... N nodes, which is called an N-way cluster (see Car- 
reira, pages 102-103). In such a system there may be 
a corresponding number of 3, 4 ... N agents and, for 
each agent, a number of policies which corresponds to 
1, 2, 3...M times the total number of monitored cluster 
packages. The agents only generate monitoring mes- 
sages with respect to the cluster package(s) running on 
the associated node, based on corresponding applica- 
tion-specific active/standby notifications or responses 
by the cluster operating system. 
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[0050] Fig. 4 illustrates a method carried out by each 
of the agents 11a, 11b, 11a*. 11b' in Figs. 2 and 3. In step 
S1, the agent 11a, 11b requests and receives active/ 
standby information from the cluster operating system 
20. In step S2 the agent receives the active/standby in- 
formation. In step S3, the agent ascertains whether the 
monitored cluster package on the associated cluster 
node 4, 5, 4', 5' is active. If the answer is positive (which 
is, for example, true for the agent 11a in the operating 
state of Fig. 2a and for the agent 11 b in the state in Fig. 
2b), in step S4 the overlaid rule 22 enables (or maintains 
enabled) the monitoring rules. If the answer is negative 
(which is, for example, true for the agent 11b in the op- 
erating state of Fig. 2a and for the agent 11 a in the one 
of Fig. 2b), in step S5 the overlaid rule 22 disables (or 
maintains disabled) the monitoring rules. In step S6 the 
agent carries out the monitoring task and generates 
"monitoring messages according to the monitoring rules 
.13, provided thaUhey have been enabled by the over- 
laid rule 22 in step S4. Step S6 can be repeated several 
times. Then, the flow proceeds further with step S1 , thus 
forming a quasi-endless monitoring loop. When a 
failover is carried out, the path carried out by the first 
node's agent 11a in Fig. 2a switches from S3-S4-S6 to 
S3-S5, whereas the path of the second node's agent 
11b switches from S3-S6 to S3-S4-S6. Fig. 4 illustrates 
the request/response embodiment - in the registration/ 
notification embodiment step S1 is omitted. 
[0051 ] Fig. 5 illustrates a process in which agents, pol- 
icies and overlaid rules are deployed by the monitoring 
server 16. In step T1, a user instructs the monitoring 
server 1 6 by means of the user interface 1 4 that a par- 
ticular node (2 or 3) shall be included in the data model 
of the.monitoring system 1 . The user also defines a pol- 
icy (monitoring rules) for that particular node. In step T2, 
the monitoring server 16 ascertains whether the node 
to be included is a standard (non-cluster) node, such as 
the node 2, or a cluster, such as the HA cluster 3. If the 
latter is true, in step T3 the monitoring server 1 6 adds 
the above-described request/response functionality to 
the agent software which is capable of monitoring the 
node and the critical application, and also adds the over- 
laid rule 22 to the standard policy 13. Then, in step T4, 
the monitoring server deploys (i.e. installs) the agent to- 
gether with the policy and the overlaid rule on each of 
the cluster nodes 4, 5. If in step T2 it has turned out that 
the node to be included is a non-cluster node 2, then, in 
step T5, the monitoring server 16 deploys a standard 
agent with a standard policy to the node 2. Again, Fig. 
5 illustrates the request/response embodiment - in the 
registration/notification embodiment, in steps T3 and T4 
the "response/request functionality" is replaced by the 
"notification function a! ity", and a further step is included 
in the left-hand branch after step T2 (e.g. after step T4) 
in which the agents are registered at the cluster operat- 
ing system. Thus, the system automatically takes into 
account whether or not a node is a cluster, when it de- 
— ploys an agent to the node. In other words, for a user 



who wants to configure the monitoring system, a cluster 
is transparent i.e. can be configured like a non-cluster 
node. 

[0052] Thus, a general purpose of the disclosed em- 
5 bodiments is to provide an improved method, computer 
system and computer program for monitoring services 
in an IT network with monitored clusters, in which no 
erroneous messages stemming from inactive cluster 
nodes have to be processed, no change to the cluster 
10 package software is required and wherein the user can 
define the policies in the same way as he could for a 
corresponding monitoring task in a non-cluster node. 

15 Claims 

1. A method of installing monitoring agents (11) on 
monitored nodes (2, 4, 5) for monitoring objects 
within an information technological network (1 ), the 

20 network (1) having non-cluster nodes (2) and at 
least one high-availability cluster (3) comprising a 
first (4) and a second cluster nodes (5), wherein at 
least one cluster package (1 0) is arranged to run on 
the high-availability cluster (3), wherein a cluster 

25 operating system (20) initiates, when a failover con- 
dition is detected for the cluster package (1 0) at the 
first cluster node (4), a failover to the second cluster 
node (5) is initiated, and 

wherein the monotoring agents (11) monitor 

30 the occurrence of events and generate event-relat- 
ed messages (15) for a monitoring server (16), 
wherein a first and second monitoring agents (11) 
associated with the first and second cluster nodes 
(4, 5) form a monitoring agent system of the cluster 

35 (3) the first and second agents (11) being arranged 
to receive information from the cluster operating 
system (20) indicating whether the cluster package 
(1 0) is currently active on the first or second cluster 
node (4, 5), respectively, wherein, depending on 

40 said information, the monitoring activity relating to 
the cluster package (10) is activated in the one of 
the first and second agents (11 ) associated with the 
cluster node (4, 5) on which the cluster package 
(1 0) is currently active and is de-activated in the oth- 

45 er one; 

the method comprising: 

automatically adapting, upon installation, the 
monitoring agents (11) which are installed on 

so the cluster nodes (4, 5) such that they are ar- 

ranged to receive the cluster-package-activity 
information and exhibit said dependency of 
their monitoring activity on cluster-package-ac- 
tivity information, whereas the monitoring 

55 agents (1 1 ) which are installed on the non-clus- 

ter nodes (2) are arranged not to exhibit a de- 
pendency of their monitoring activity on cluster- 
package-activity. 
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2. The method of claim 1 , wherein the agents (11) gen- 
erate the messages (15) according to monitoring 
rules, wherein, if an agent (1 1 ) is installed on a clus- 
ter node (4, 5), at least one overlaid rule (22) per- 
taining to cluster package activity is automatically 
added, according to which the agent (11) does not 
evaluate the monitoring rules if the cluster-pack- 
age-activity information indicates that the cluster 
package (1 0) is inactive on the cluster node (4, 5) 
with which the agent (11) is associated. 

3. The method of claim 2, wherein the agents (11) gen- 
erate messages according to monitoring rules 
which can be defined by a user, wherein, due to the 
automatic adaptation of the agents (11) upon the 
installation, the definition of monitoring tasks is the 
same for a monitored cluster (3) as for a non-cluster 
node (2). 

4. The method of any one of claims 1 to 3, wherein, if 
an agent (11) is installed on a cluster node (4, 5), 
an interface to the cluster operating system (20) for 
the receipt of the cluster-package-activity informa- 
tion is automatically installed. 

5. The method of any one of claims 1 to 4, wherein the 
agents (11 ) installed on cluster nodes (4, 5) are ar- 
ranged to send requests for the cluster-package- 
activity information to the cluster operating system 
(20) and receive corresponding responses from it. 

6. The method of any one of claims 1 to 4, wherein the 
agents (11) installed on cluster nodes (4, 5) are ar- 

ranged to receive the cluster-package-activity infor- 
mation in the form of notifications from the cluster 
operating system (20) in at least one of the following 
ways: i) periodically, and ii) upon a change of the 
activity status of the cluster package (10). 

7. A system for monitoring objects within an informa- 
tion technological network (1) including a monitor- 
ing server (16) and monitored nodes (2, 4, 5), com- 
prising: 

non-cluster nodes (2) and at least one high- 
availability cluster (3) comprising first and sec- 
ond cluster nodes (4, 5) and a cluster operating 
system (20) which initiates, when a failover 
condition is detected for a cluster package (10) 
running on the first cluster node (4), a failover 
to the second cluster node (5); 
monitoring agents (11) which, when installed on 
the non-cluster nodes (2) or the cluster nodes 
(4, 5), monitor the occurrence of events and 
generate event-related messages (15) for the 
monitoring server (16), wherein first and sec- 
ond monitoring agents (11) installed on and as- 
sociated with the cluster nodes (4, 5) form a 



monitoring agent system of the cluster (3), 
wherein the first and second agents (11) re- 
ceive information from the cluster operating 
system (20) indicating whether the cluster 

5 package (10) is currently active on the associ- 

ated cluster node (4, 5), wherein, depending on 
said information, the monitoring activity relating 
to the cluster package (10) is activated in the 
one of the first and second agents (11 ) which is 

10 associated with the cluster node (4, 5) on which 

the cluster package (10) is currently active and 
is de-activated in the other one, 

wherein the agents (11) are automatically 
15 adapted, upon installation on a cluster node (4, 5), 
to receive the cluster-package-activity information 
and exhibit said dependency of their monitoring ac- 
tivity on cluster-package-activity information, but, 
upon installation on a non-cluster node (2), not to 
20 exhibit a dependency of their monitoring activity on 
cluster-package-activity. 

8. The system of claim 7, wherein the agents (1 1 ) gen- 
erate the messages (15) according to monitoring 

25 rules, wherein, if an agent (1 1 ) is installed on a clus- 
ter node (4, 5), at least one overlaid rule (22) per- 
taining to cluster package activity is automatically 
added, according to which the agent (11) does not 
evaluate the monitoring rules if the cluster-pack- 

30 age-activity information indicates that the cluster 
package is inactive on the cluster node (4, 5) with 
which the agent (11) is associated. 
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9. The system of claim 8, wherein the agents (1 1 ) gen- 
erate messages (15) according to monitoring rules 
which can be defined by a user, wherein, due to the 
automatic adaptation of the agent (11) upon the in- 
stallation, the definition of monitoring tasks is the 
same for a monitored cluster (3) as for a non-cluster 
node (2). 



10. The system of any one of claims 7 to 9, wherein the 
agents (11 ) installed on cluster nodes (4, 5) are ar- 
ranged to send requests for the cluster-package- 

45 activity information to the cluster operating system 
(20) and receive corresponding responses from it. 

1 1 . The system of any one of claims 7 to 9, wherein the 
agents (11 ) installed on cluster nodes (4, 5) are ar- 

50 ranged to receive the cluster-package-activity infor- 
mation in the form of notifications from the cluster 
operating system (20) in at least one of the following 
ways: i) periodically, and ii) upon a change of the 
activity status of the cluster package (10). 

55 

1 2. A computer program including program code for ex- 
ecution on a network (1) comprising a monitoring 
server (1 6) and monitored nodes (2, 4, 5), including 



10 



19 



EP1 320 217 B1 



20 



non-cluster nodes (2) and at least one high-availa- 
bility cluster (3) comprising first and second cluster 
nodes (4, 5) and a cluster operating system (20) 
which initiates, when a failover condition is detected 
for a cluster package (10) running on the first cluster 5 
node (4), a failover to the second cluster node (5), 

said program code constituting, when in- 
stalled on the non-cluster nodes (2) or the cluster 
nodes (4, 5), an agent (1 1 ) for monitoring the occur- 
rence of events and generating event-related mes- to 
sages (15) for the monitoring server (16), wherein 
first and second agents (11), when installed on the 
cluster nodes (4, 5) of the cluster (3), form a moni- 
toring agent system, wherein the first and second 
agents (11) receive information from the cluster op- 15 
erating system (20) indicating whether the cluster 
package (10) is currently active on the associated 
cluster node (4, 5), wherein, depending on said in- 
formation, the monitoring activity relating to the 
cluster package (10) is activated in the one of the 20 
first and second agents (11) which is associated 
with the cluster node (4, 5) on which the cluster 
package (1 0) is currently active and is de-activated 
in the other one; 

wherein the agents (11) are automatically 25 
configured, upon installation on a cluster node (4, 
5), to receive the cluster-package-activity informa- 
tion and exhibit said dependency of their monitoring 
activity on cluster-package-activity information, but, 
upon installation on a non-cluster node (2), not to 30 
exhibit a dependency of their monitoring activity on 
cluster-package-activity. 

13. The computer program of claim 12, wherein the 
agents (11) generate the messages (15) according 35 
to monitoring rules, wherein, if an agent (11) is in- 
stalled on a cluster node (4, 5), at least one overlaid 
rule (22) pertaining to cluster package activity is 
able to be automatically be added, according to 
which the agent (11) does not evaluate the monitor- 40 
ing rules if the cluster-package-activity information 
indicates that the cluster package is inactive on the 
cluster node (4, 5) with which the agent (11) is as- 
sociated. 

45 

14. The computer program of claim 13 , wherein the 
agents (11) generate messages (15) according to 
monitoring rules which can be defined by a user, 
wherein, due to the automatic configuration of the 
agent upon the installation, the definition of moni- so 
toring tasks is the same for a monitored cluster (3) 

as for a non-cluster node (2). 

15. The computer program of any one of claims 12 to 

15, wherein the agents (11) installed on cluster 55 
nodes (4, 5) are arranged to send requests for the 
cluster-package-activity information to the cluster 
operating system (20) and receive corresponding 



responses from it. 

16. The computer program of any one of claims 12 to 
15, wherein the agents (11) installed on cluster 
nodes (4, 5) are arranged to receive the cluster- 
package-activity information in the form of notifica- 
tions from the cluster operating system (20) in at 
least one of the following ways: i) periodically, and 
ii) upon a change of the activity status of the cluster 
package (10). 



Patentanspruche 

1. Verfahren zum Installieren von Uberwachungs- 
agenten (11) an uberwachten Knoten (2, 4, 5) zum 
Uberwachen von Objekten in einem informations- 
technologischen (IT) Netzwerk (1), wobei das 
IT-Netzwerk (1) Nichtclusterknoten (2) und minde- 
stens einen Hochverf ugbarkeitscluster (3) aufweist, 
welcher einen ersten (4) und einen zweiten Cluster- 
knoten (5) umfasst, wobei mindestens ein Cluster- 
paket (10) dazu eingerichtet ist, auf dem Hochver- 
fugbarkeitsctuster (3) zu laufen, wobei ein Cluster- 
betriebssystem (20), wenn eine Failover-Bedin- 
gung fur das Clusterpaket (10) am ersten Cluster- 
knoten (4) detektiert wird, einen Failover zum zwei- 
ten Clusterknoten (5) initiiert, und 

wobei die Uberwachungsagenten (11) das 
Auftreten von Ereignissen uberwachen und ereig- 
nisbezogene Nachrichten (15) fur einen Uberwa- 
chungsserver (16) erzeugen, wobei ein erster und 
zwetter Uberwachungsagent (11), welche dem er- 
sten und zweiten Clusterknoten (3, 4) zugeordnet 
sind ein Uberwachungsagentensystem des Clu- 
sters (3) bilden, wobei der erste und zweite Agent 
(11) des Uberwachungsagentensystems dazu ein- 
gerichtet sind, Information von dem Clusterbe- 
triebssystem (20) zu empfangen, welche angibt, ob 
das Clusterpaket (10) gegenwartig auf dem ersten 
Oder zweiten Clusterknoten (4, 5) aktiv ist, wobei in 
Abhangigkeit von dieser Information die auf das 
Clusterpaket (10) bezogene Oberwachungsaktivi- 
tat in demjenigen des ersten und zweiten, dem Clu- 
sterknoten (4, 5) zugeordneten Agenten (11) akti- 
viert wird, auf welchem das Clusterpaket (10) ge- 
genwartig aktiv ist, und auf dem anderen deaktiviert 
wird; 

wobei das Verfahren folgendes umfasst: 

bei der Installation, automatisches Anpassen 
der Uberwachungsagenten (11), welche auf 
den Clusterknoten (4, 5) installiert werden, der- 
ail, dass sie zum Empfangen der Clusterpa- 
ketaktivitats information eingerichtet sind und 
die Abhangigkeit ihrer Uberwachungsaktivitat 
von der Clusterpaketaktivitatsinformation auf- 
weisen, wohingegen die Oberwachungsagen- 
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ten (11), welche auf den Nichtclusterknoten (2) 
installiert werden dazu eingerichtet sind, keine 
Abhangigkeit ihrer Uberwachungsaktivitat von 
Clusterpaketsaktivitat aufzuweisen. 

2. Verfahren nach Anspruch 1 , wobei die Agenten (11 ) 
die Nachrichten (15) gemaB Uberwachungsregeln 
erzeugen, wobei, falls ein Agent (1 1 ) auf einem Clu- 
sterknoten (4, 5) installiert wird, wenigstens eine die 
Clusterpaketsaktivitat betreffende, uberlagerte Re- 
gel (22) automatisch hinzugefugt wird, gemaB wel- 
cher der Agent (11) nicht die Uberwachungsregeln 
auswertet, falls die Clusterpaketsaktivitatsinforma- 
tion anzeigt, dass das Clusterpaket (10) auf dem 
Clusterknoten (4, 5) inaktiv ist, welchem der Agent 
(11) zugeordnet ist. 

3. Verfahren nach Anspruch 2, wobei die Agenten (11) 
Nachrichten gemaB. Uberwachungsregeln erzeu- 
gen, welche von einem Nutzer definiert werden 
konnen, wobei aufgrund der automatischen Anpas- 
sung der Agenten (11) bei der Installation die Defi- 
nition von Uberwachungsaufgaben fur einen iiber- 
wachten Cluster (3) dieselbe wie fur einen Nichtclu- 
sterknoten (2) ist. 

4. Verfahren nach einem der Anspruche 1 bis 3, wo- 
bei, falls ein Agent (1 1 ) auf einem Clusterknoten (4, 
5) installiert wird, eine Schnittstelle zum Clusterbe- 
triebssystem (20) fur den Empfang der Clusterpa- 
ketaktivitatsinformation automatisch installiert wird. 

5. Verfahren nach einem der Anspruche 1 bis 4, wobei 
_die auLCIusterknoten (4, 5) installierten Agenten 

(11) dazu eingerichtet sind, Abfragen der Cluster- 
paketsaktivitatsinformation an das Clusterbetriebs- 
system (20) zu senden und entsprechende Antwor- 
ten von diesem zu empfangen. 

6. Verfahren nach einem der Anspruche 1 bis 4, wobei 
die auf Clusterknoten (4, 5) installierten Agenten 
(11) dazu eingerichtet sind, die Clusterpaketaktivi- 
tatsinformation in Form von Meldungen von dem 
Clusterbetriebssystem (20) auf wenigstens eine der 
folgenden Arten zu empfangen: i) periodisch und ii) 
auf einen Wechsel des Aktivitatsstatus des Cluster- 
pakets (10) hin. 

7. System zum Uberwachen von Objekten innerhalb 
eines informationstechnologischen Netzwerks (1), 
welches einen Uberwachungsserver (1 6) und uber- 
wachte Knoten (2, 4, 5) einschlieBt, umfassend: 

Nichtclusterknoten (2) und mindestens einen 
Hochverfugbarkeitscluster (3), welcher einen 
ersten und zweiten Clusterknoten (4, 5) und ein 
Clusterbetriebssystem (20) umfasst, welches, 
- - — wenn eine Failover-Bedingung fur ein auf dem 



ersten Clusterknoten (4) laufendes Clusterpa- 
ket (10) detektiert wird, einen Failover zum 
zweiten Clusterknoten (5) initiiert; 
Uberwachungsagenten (11), welche, wenn sie 

5 auf den Nichtclusterknoten (2) Oder den Clu- 

sterknoten (4, 5) installiert sind, das Auftreten 
von Ereignissen uberwachen und ereignisbe- 
zogene Nachrichten (15) fur den Uberwa- 
chungsserver (16) erzeugen, wobei erste und 

10 zweite, auf den Clusterknoten (4, 5) installierte 

und ihnen zugeordnete Oberwachungsagen- 
ten (11) ein Oberwachungsagentensystem des 
Clusters (3) bilden, wobei die ersten und zwei- 
ten Agenten (11) Information von dem Cluster- 

15 betriebssystem (20) empfangen, welche an- 

zeigt, ob das Clusterpaket (1 0) gegenwartig auf 
dem zugehorigen Clusterknoten (4, 5) aktiv ist, 
wobei in Abhangigkeit von der Information die 
.auf das Clusterpaket (10) bezogene Uberwa- 

20 chungsaktivitat in demjenigen des ersten und 

zweiten, dem Clusterknoten (4, 5) zugeordne- 
ten Agenten (11) aktiviert ist, auf welchem das 
Clusterpaket (10) gegenwartig aktiv ist, und auf 
dem anderen deaktiviert ist, 

25 

wobei die Agenten (11) bei Installation auf ei- 
nem Clusterknoten (4, 5) automatisch dazu ange- 
passt werden die Clusterpaketaktivitatsinformation 
zu empfangen und die Abhangigkeit ihrer Uberwa- 
30 chungsaktivitat von Clusterpaketaktivitatsinformati- 
on aufzuweisen, aber bei Installation auf einem 
Nichtclusterknoten (2) nicht keine Abhangigkeit ih- 
rer Uberwachungsaktivitat von Clusterpaketaktivi- 
_tat aufzuweisen. 

35 

8. System nach Anspruch 7, wobei die Agenten (11) 
die zu Uberwachungsregeln gehorigen Nachrichten 
(1 5) erzeugen, wobei, falls ein Agent (1 1 ) auf einem 
Clusterknoten (4, 5) installiert ist, wenigstens eine 

40 die Clusterpaketaktivitat betreffende, uberlagerte 
Regel (22) automatisch hinzugefugt wird, gemaB 
welcher der Agent (11) nicht die Oberwachungsre- 
geln auswertet, falls die Clusterpaketaktivitatsinfor- 
mation anzeigt, dass das Clusterpaket auf dem Clu- 

45 sterknoten (4, 5), welchem der Agent (11) zugeord- 
net ist, inaktiv ist. 

9. System nach Anspruch 8, wobei die Agenten (11) 
Nachrichten (15), welche Uberwachungsregeln zu- 

50 geordnet sind, welche durch einen Nutzer definiert 
werden konnen, erzeugen, wobei aufgrund der au- 
tomatischen Anpassung des Agenten (11) nach In- 
stallation die Definition von Uberwachungsaufga- 
ben fur einen uberwachten Cluster (3) dieselbe wie 

55 fur einen Nichtclusterknoten (2) ist. 

10. System nach einem der Anspruche 7 bis 9, wobei 
die auf Clusterknoten (4, 5) installierten Agenten 
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(11) dazu eingerichtet sind, Abfragen der Cluster- 
paketaktivitatsinformation an das Clusterbetriebs- 
system (20) zu senden und entsprechende Antwor- 
ten von diesem zu empfangen. 

11. System nach einem der Anspruche 7 bis 9, wobei 
die auf Clusterknoten (4, 5) installierten Agenten 
(11) dazu eingerichtet sind, die Clusterpaketaktivi- 
tatsinformation in Form von Meldungen von dem 
Clusterbetriebssystem (20) auf wenigstens eine der 
folgenden Allen zu empfangen: i) periodisch und ii) 
auf einen Wechsel des Aktivitatsstatus des Cluster- 
pakets (10) hin. 

12. Computerprogramm, umfassend Programmcode 
zur Ausfuhrung auf einem Netzwerk (1 ), welches ei- 
nen Uberwachungsserver (16) und uberwachte 
Knoten (2, 4, 5), umfasst, welche einschlieBlich 
Nichtclusterknoten (2) und wenigstens einen Hoch- 
verfugbarkeitscluster (3) umfassen, der einen er- 
sten und zweiten Clusterknoten (4, 5) und ein Clu- 
sterbetriebssystem (20) umfasst, welches, wenn ei- 
ne Failover-Bedingung fur ein auf dem ersten Clu- 
sterknoten (4) betriebenes Clusterpaket (1 0) detek- 
tiert wird, einen Failover zum den zweiten Cluster- 
knoten (5) initiiert, 

wobei der Programmcode, wenn er auf den 
Nichtclusterknoten (2) Oder den Clusterknoten (4, 
5) installiert ist, einen Agenten (11) zum Uberwa- 
chen des Auftretens von Ereignissen und zum Er- 
zeugen ereignisbezogener Nachrichten (15) fur 
den Uberwachungsserver (16) darstellt, wobei der 
erste und zweite Agent (11 ), wenn sie auf den Clu- 
sterknoten (4, 5) des Clusters (3) installiert sind, ein 
Oberwachungsagentensystem bilden, wobei der 
erste und zweite Agent (11) Information von dem 
Clusterbetriebssystem (20) empfangen, welche an- 
zeigt, ob das Clusterpaket (10) gegenwartig auf 
dem zugehorigen Clusterknoten (4, 5) aktiv ist, wo- 
bei in Abhangigkeit von der Information die auf das 
Clusterpaket (10) bezogene Uberwachungsaktivi- 
tat in demjenigen des ersten und zweiten, dem Clu- 
sterknoten (4, 5) zugeordneten Agenten (11) akti- 
viert wird, auf welchem das Clusterpaket (10) ge- 
genwartig aktiv ist, und auf dem anderen deaktiviert 
wird; 

wobei die Agenten (11) bei Installation auf ei- 
nem Clusterknoten (4, 5) automatisch dazu konfi- 
guriert werden, die Clusterpaketaktivitatsinformati- 
on zu empfangen und die Abhangigkeit der Ober- 
wachungsaktivitat von Clusterpaketaktivitatsinfor- 
mation aufzuweisen, aber bei Installation auf einem 
Nichtclusterknoten (2) keine Abhangigkeit ihrer 
Uberwachungsaktivitat vom Clusterpaketaktivitat 
aufzuweisen. 

13. Computerprogramm nach Anspruch 12, wobei die 
Agenten (11) die Nachrichten (15) gemaG Oberwa- 



chungsregeln erzeugen, wobei, falls ein Agent (11) 
auf einem Clusterknoten (4, 5) installiert ist, wenig- 
stens eine die Clusterpaketaktivitat betreffende 
uberlagerte Regel (22) automatisch hinzugefugt 
s werden kann, gemaB welcher der Agent (11 ) nicht 
die Uberwachungsregeln auswertet, falls die Clu- 
sterpaketaktivitatsinformation anzeigt, dass das 
Clusterpaket auf dem Clusterknoten (4, 5), wel- 
chem der Agent (11) zugeordnet ist, inaktiv ist. 

10 

14. Computerprogramm nach Anspruch 13, wobei die 
Agenten (11) Nachrichten (15) erzeugen, welche 
Uberwachungsregeln zugeordnet sind, welche 
durch einen Nutzer definiert werden konnen, wobei 
is aufgrund der automatischen Konfiguration des 
Agenten nach Installation die Definition von Uber- 
wachungsaufgaben fur einen uberwachten Cluster 
(3) dieselbe wie fur einen Nichtclusterknoten (2) ist. 

20 15. Computerprogramm nach einem der Anspruche 12 
bis 15, wobei die auf Clusterknoten (4, 5) installier- 
ten Agenten (11) dazu eingerichtet sind, Abfragen 
der Clusterpaketaktivitatsinformation an das Clu- 
sterbetriebssystem (20) zu senden und entspre- 

25 chende Antworten von diesem zu empfangen. 

16. Computerprogramm nach einem der Anspruche 12 
bis 15, wobei die auf Clusterknoten (4, 5) installier- 
ten Agenten (11) dazu eingerichtet sind, die Clu- 
30 sterpaketaktivitatsinformation in Form von Meldun- 
gen von dem Clusterbetriebssystem (20) auf wenig- 
stens eine der folgenden Arten zu empfangen: I) pe- 
riodisch und ii) auf einen Wechseln des Aktivitats- 
status des Clusterpakets (1 0) hin. 

35 

Revendications 

1 . Procede" d'installation d'agents (1 1 ) de surveillance 

40 sur des noeuds (2, 4, 5) surveiltes, pour la sur- 
veillance d'objets a I'interieur d'un r6seau (1) de 
technologie de reformation, le r6seau (1 ) ayant des 
noeuds (2) non Ii6s a un groupe et au moins un 
noeud (3) a haute disponibilite, comprenant des 

45 premier (4) et second (5) noeuds de groupe, dans 
lequel au moins un progiciel (10) de groupe est 
agence" pour opener sur le groupe (3) a haute dis- 
ponibilite, dans lequel un systeme (20) qui opere 
sur un groupe lance une instruction, lorsqu'unecon- 

50 dition de permutation est d6tect6e sur le progiciel 
(10) de groupe au niveau du premier noeud (4) de 
groupe, qui initie une permutation vers le second 
noeud (5) de groupe, et 

dans lequel les agents (11) de surveillance 

55 d6tectent Toccurrence d'un 6v6nement et g§nerent 
des messages (15) relatifs a I'6v6nement pour un 
serveur (16) de surveillance, dans lequel des pre- 
mier et second agents ( 1 1 ) de surveillance associes 
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aux premier et second noeuds (4, 5) de groupe tor- 
ment un systeme d'agents de surveillance du grou- 
pe (3), les premier et second agents (11) etant 
agenc6s pour recevoir information provenant du 
systeme (20) de fonctionnement du groupe qui in- 5 
dique si le progiciel (10) de groupe estcouramment 
actif sur les premier et second noeuds (4, 5) de 
groupe respectivement, dans lequel, en fonction de 
ladite information, I'activite de surveillance relative 
au progiciel (1 0) de groupe est activ6e sur Tun des io 
premier et second agents (11) associ6s aux noeuds 
(4, 5) de groupe, sur lequel le progiciel (1 0) de grou- 
pe est couramment actif sur I'un et desactive* sur 
I'autre ; 

le proced§ comprenant : is 

I'adaptation automatique, en cours d'installa- 
tion, des agents (11) de surveillance installes 
sur les noeuds (4, 5) de groupe, de maniere a 
ce qu'ils soient agenc6s pour recevoir I'informa- 20 
tion d'activite du progiciel de groupe, grSce a 
quoi les agents (11) de surveillance qui sont 
installes sur les noeuds (2) non lies a un groupe 
sont agences pour ne pas presenter une d6- 
pendance de leur activity de surveillance par 25 
rapport a I'activite du progiciel de groupe. 

2. Proc6d6 selon la revendication 1 , dans lequel les 
agents (11) generent les messages (15) selon des 
regies de surveillance, selon lesquelles si un agent 30 
(11) est instalie sur un noeud (4, 5) de groupe, au 
moins une regie (22) en vigueur concernant I'acti- 
vite du progiciel de groupe est ajoutee automatique- 
ment, d'apres laquelle I'agent (11) n'evalue pas les 
regies de surveillance si I'information d'activite du 35 
progiciel de groupe indique que le progiciel (10) de 
groupe est inactif sur le noeud (4, 5) de groupe 
auquel I'agent (1 1 ) est assocte. 

3. Proc6d6 selon la revendication 2, dans lequel les *o 
agents (11) g6nerent des messages selon des re- 
gies de surveillance qui peuvent §tre definies par 
I'utilisateur, dans lequel, du fait de I'adaptation auto- 
matique des agents (11) au cours de I'installation, 

la definition des taches de surveillance est la meme 4 $ 
pour un groupe surveilte (3) comme pour un noeud 
(2) non lie a un groupe. 

4. Proc6d6 selon Tune quelconque des revendications 

1 a 3, dans lequel, si un agent (11) est install^ sur so 
un noeud (4, 5) de groupe, une interface avec le 
systeme (20) qui opere sur le groupe pour la recep- 
tion de I'information d'activite de progiciel de groupe 
est installed automatiquement. 

55 

5. Proc6d6 selon I'une quelconque des revendications 
1 a 4, dans lequel les agents (11) installes sur des 
noeuds (4, 5) de groupe sont agenc§s pour envoyer 



des demandes d'information d'activite du progiciel 
de groupe au systeme (20) qui opere sur le groupe 
et pour en recevoir des teponses correspondantes. 

6. Proc§d§ selon I'une quelconque des revendications 
1 a 4, dans lequel les agents (11) installs sur des 
noeuds (4, 5) de groupe sont agenc6s pour recevoir 
I'information d'activite du progiciel de groupe sous 
la forme d'une notification provenant du systeme 
(20) qui opere sur le groupe selon au moins I'un des 
modes suivants : i) p6riodiquement, et ii) au cours 
d'un changement du statut d'activite du progiciel 
(10) de groupe. 

7. Systeme de surveillance d'objets a I'interieur d'un 
reseau (1) de technologie de I'information compre- 
nant un serveur (16) de surveillance et des noeuds 

""(274, 5)'surveiltes comprenant : 

des noeuds (2) non Ii6s a un groupe et au moins 
un groupe (3) a haute disponibilite incluant des 
premier et second noeuds (4, 5) de groupe et 
un systeme (20) qui opere sur un groupe et qui 
initie, lors de la detection d'une condition de 
permutation d'un progiciel (10) de groupe exe- 
cute sur le premier noeud (4) de groupe, une 
permutation sur le second noeud (5) de 
groupe ; 

des agents (11) de surveillance qui, une fois 
installed sur les noeuds (2) non liSs a un groupe 
ou sur les noeuds (4, 5) de groupe, surveillent 
I'occurrence d'6v6nements et generent des 
messages (15) relatifs a ces eAtenements pour 
... le serveur (16) de surveillance, dans lequel les 
premier et second agents (11) de surveillance 
installs sur et associ6s aux noeuds (4, 5) de 
groupe torment un systeme d'agents de sur- 
veillance du groupe (3), 

dans lequel les premier et second agents (11) re- 
goivent des informations du systeme (20) qui opere 
sur le groupe indiquant si le progiciel (1 0) de groupe 
est couramment actif sur le noeud (4, 5) de groupe 
assocte, dans lequel en fonction de ladite informa- 
tion I'activite de surveillance relative au progiciel 
(10) de groupe est activ6e sur I'un des premier et 
second agents (11) assocte au noeud (4, 5) du grou- 
pe sur lequel le progiciel (10) de groupe est cou- 
ramment actif et d6sactiv6 sur I'autre, 

dans lequel les agents (11) sont automatique- 
ment adaptes, en cours d'installation sur le noeud 
(4, 5) de groupe, pour recevoir une information d'ac- 
tivite du progiciel de groupe et pour presenter ladite 
dependance de leur activite de surveillance a Tin- 
formation d'activite de progiciel de groupe, mais qui 
au cours de I'installation d'un noeud (2) non lie" a un 
groupe ne presente pas de dependance par rapport 
a leur activite de surveillance sur I'activite du progi- 
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ciel de groupe. 

8. Systeme selon la revendication 7, dans lequel les 
agents (11) g§nerent les messages (15) selon des 
regies de surveillance, dans lequel si un agent (11) 
est installe sur un noeud (4, 5) de groupe, au moins 
une regie (22) en vigueur, relative a I'activite du pro- 
giciel de groupe, est ajoutee automatiquement, se- 
lon laquelle I'agent (11) n'evalue pas les regies de 
surveillance si I'information de I'activite du progiciel 
de groupe indique que le progiciel de groupe est 
inactif sur le noeud (4, 5) du groupe avec lequel 
I'agent (11) est associe. 

9. Systeme selon la revendication 8, dans lequel les 
agents (1 1 ) g6nerent des messages (1 5) selon des 
regies de surveillance qui peuvent §tre definies par 
I'utilisateur, dans lequel, du faitde I'adaptation auto- 
matique de I'agent (11) au cours de I'installation, la 
definition des taches de surveillance est la meme 
pour un groupe (3) surveille et pour un noeud (2) 
non lie a un groupe. 

10. Systeme selon I'une quelconque des revendica- 
tions 7 a 9, dans lequel les agents (11) installs sur 
des noeuds (4, 5) de groupe sont agences pour en- 
voyer des demandes d'information d'activite de pro- 
giciel de groupe au systeme (20) qui opere sur le 
groupe et en regoit des reponses correspondantes. 

11. Systeme selon I'une quelconque des revendica- 
tions 7 a 9, dans lequel les agents (11) installes sur 
des noeuds (4, 5) de groupe sont agences pour re- 
cevoir I'information d'activite du progiciel de groupe 
sous la forme de notifications provenant du syste- 
me (20) de fonctionnement de groupe selon Tun au 
moins des modes suivants : i) pe>iodiquement, et ii) 
lors d'un changement du statut d'activite du progi- 
ciel (10) de groupe. 

12. Programme d'ordinateur comprenant un code de 
programme d'execution sur un r§seau (1) incluant 
un serveur (16) de surveillance et des noeuds (2, 
4, 5) surveilles, comprenant des noeuds (2) non lies 
a un groupe et au moins un groupe (3) a haute dis- 
ponibilite comprenant des premier et second 
noeuds (4, 5) de groupe et un systeme (20) opera- 
tionnel qui initie, lorsqu'une condition de permuta- 
tion est detectee pour un progiciel (10) de groupe 
execute sur le premier noeud (4) de groupe, une 
permutation sur le second noeud (5) de groupe, 

ledit code de programme constituant, une fois 
installe sur le noeud (2) non lie a un groupe ou sur 
des noeuds (4, 5) de groupe, un agent (11) pour 
surveiller I'occurrence d'evenements et pour gene- 
rer des messages (15) relatifs a ces evenements 
pour le serveur (16) de surveillance, dans lequel les 
premier et second agents (1 1 ) une fois installes sur 



les noeuds (4, 5) du groupe (3) forment un systeme 
d'agents de surveillance, dans lequel les premier et 
second agents (11) regoivent des informations du 
systeme (20) de fonctionnement du groupe indi- 

5 quant si le progiciel (10) est couramment actif sur 
le noeud (4, 5) de groupe associe, dans lequel, en 
fonction de ladite information, I'activite de sur- 
veillance relative au progiciel (1 0) de groupe est ac- 
tivee dans I'un des premier et second agents (11) 

10 associe au noeud (4, 5) de groupe sur lequel le pro- 
giciel (10) de groupe est couramment actif, et il est 
d§sactive sur I'autre ; 

dans lequel les agents (11) sont configures 
automatiquement, au cours de I'installation sur un 

15 noeud (4, 5) de groupe, pour recevoir une informa- 
tion d'activite de progiciel de groupe et pour presen- 
ter ladite dependance de leur activite de surveillan- 
ce par rapport a I'information d'activite de progiciel 
de groupe, mais qui au cours de I'installation d'un 

20 noeud (2) non lie a un groupe ne doit pas presenter 
une dependance par rapport a leur activite de sur- 
veillance par rapport a I'activite du progiciel de grou- 
pe. 

25 13. Programme d'ordinateur selon la revendication 12, 
dans lequel les agents (11) genfcrent les messages 
(1 5) en fonction de regies de surveillance, dans le- 
quel si un agent (11) est installe sur un noeud (4, 5) 
de groupe, au moins une regie (22) en vigueur, re- 

30 lative a I'activite du progiciel de groupe, peut etre 
ajoutee automatiquement, selon laquelle I'agent 
(11) n'a pas a 6valuer les regies de surveillance si 
I'information de I'activite du progiciel de groupe in- 
dique que le progiciel de groupe est inactif sur le 

35 noeud (4, 5) du groupe avec lequel I'agent (11) est 
associe. 

14. Programme d'ordinateur selon la revendication 13, 
dans lequel les agents (1 1 ) generent des messages 

40 (1 5) en fonction de regies de surveillance qui peu- 
vent etre definies par I'utilisateur, dans lequel, du 
fait de la configuration automatique de I'agent (11) 
au cours de I'installation, la definition des taches de 
surveillance est la m§me pour un groupe (3) sur- 

45 veilie comme pour un noeud (2) non lie a un groupe. 

15. Programme d'ordinateur selon I'une quelconque 
des revendications 12 a 15, dans lequel les agents 
(11) installes sur des noeuds (4, 5) de groupe sont 

so agences pour envoyer des demandes d'informa- 
tions d'activite de progiciel de groupe au systeme 
(20) de fonctionnement de groupe et pour en rece- 
voir des reponses correspondantes. 

55 16. Programme d'ordinateur selon I'une quelconque 
des revendications 12 a 15, dans lequel les agents 
(11) installes sur des noeuds (4, 5) de groupe sont 
agences pour recevoir I'information d'activite de 
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progiciel de groupe sous la forme de notifications 
provenant du systeme (20) de fonctionnement de 
groupe selon au moins un des modes suivants : i) 
periodiquement, et ii) au cours d'un changement de 
statut d'activite du progiciel (10) de groupe. 
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